Skip to content

Conversation

ilevkivskyi
Copy link
Member

While trying this I found that this is a bit fragile, in the sense that write_tag(data, 1) (with a literal 1) will not get specialized and will go through slow path (btw @JukkaL is this a bug, should type of a literal in fixed int type context be inferred as fixed int?) OTOH this is probably not a big deal since no-one will use write_tag() with literals, it will always be something like write_tag(data, FUNC_DEF).

This comment has been minimized.

@JukkaL
Copy link
Collaborator

JukkaL commented Aug 27, 2025

btw @JukkaL is this a bug, should type of a literal in fixed int type context be inferred as fixed int

Yes, a literal integer should always be valid if u8 is expected. I checked that this works at least in simple cases, like def f(x: u8) -> None followed by f(2).

assert read_tag(b) == 33
assert read_tag(b) == 255
assert read_tag(b) == TAG_A
assert read_tag(b) == TAG_B
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try reading the error value (when there is no error).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, good idea, I will add it to both compiled and interpreted tests.

@ilevkivskyi
Copy link
Member Author

@JukkaL

I checked that this works at least in simple cases

To be clear, it doesn't give an error, but mypyc generates slow code in case where I would expect it to generate fast code. Looking more at this, I think this works correctly for code like x // 2 because we normally use custom_op for other fixed-width-related specializations, and then they are applied "manually". I think we can make mypyc a bit "smarter", so that e.g. function_op() (like I use in this PR) will be applied in more cases, but this looks low priority now.

Copy link
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

@ilevkivskyi ilevkivskyi merged commit abd9424 into python:master Aug 27, 2025
20 checks passed
@ilevkivskyi ilevkivskyi deleted the use-u8 branch August 27, 2025 23:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants